Amiga ISO Collection/AmigaUtilCD2.iso/Programming/Misc/LK_V1.06.LHA/LK V1.06/HELP/purpose.hlp

INI File | 1994-11-01 | 5.4 KB | 123 lines

[LANGUAGE english; PARENT index; PAGE 16]
[C;6;B]        The purpose of lk
[J;1;N]
  lk is a linker editor. It may be used to link any object all \
together. Objects can be created with any language and compiler \
or assembler which generate normal Amiga object files (Also \
not AztecC from manx.)

  Four ways to use lk:
[INDENT 7]    1. Link object files to generate an executable.
    2. Link object files to generate a library (.Lib file.)
    3. "Link" an executable to remove symbols and debugs and \
ask for small code, data and bss hunks.
       This may eventually be used to force all the program \
to be loaded in a specific memory type, reshoot relocation \
table from long to short, and some more.
    4. Fix code, data and bss hunks to a specific address.
       This is essential for people which are building games \
or ROMs.
[INDENT]
  The first way is the first purpose of lk. When you need to \
create very large programs, it will be more convenient to make \
each function in a single file, and then link all object files \
to generate the program.

  The second function was created to enable anyone to generate \
libraries with a more convenient way than with a JOIN function \
of the AmigaDOS shell. \
When files pass trough lk for this purpose, lk may already \
link some hunks together (This is done this way to ensure a \
better linking time. Of course, only hunks which needs each \
other will be linked in a single one.)

  The third way can be useful to eliminate debug and symbol hunks \
from executable files. And this is possible whenever you do not \
have the source object files (The future AmigaDOS loadings will \
automatically be faster!)

  The forth option will be used only by people which does not \
want to use AmigaDOS. This will create plain binary files \
without the reloc tables because it already is positionned. \
Game and ROMs are only two examples, this features might be \
used for other purpose like Unix codes (Which usuly are \
loaded at a fixed address.)
  The debug and symbol tables are freed too.
  See also the following keyword for more informations:
[C;3][LINK address]        ADDRESS
[J;1]
  Whenever possible lk will prompt you about a bizarre object(s). \
To eliminate most or all of lk warnings, see:
[C;3; LINK quiet]        QUIET (Default)
[LINK warninglevel]        WARNINGLEVEL
[LINK nowarning]        NOWARNING
[J;1]To disable the reloc32 and ref32 to generate overflow (which \
should never happen, but...) use the flag:
[C;3][LINK nooverflow32]    NOOVERFLOW32
[J;1]
  All source hunks with the same name will be linked together, \
creating one hunk. Some special keywords may be used to force \
other hunks to be linked together. Note that there is no  way \
to avoid hunks with the same name to be appended one after \
another. The given order of the source files will always be \
keept inside the resulting file.
  Note: most of linkers, which support a function to link hunks \
together, will not check memory requirements correctly. But lk \
does that for you. Anyway you may not use these functions.

  Because some compilers or assemblers does not support a way \
to specify specific memory requirements, 'lk' have special \
keywords for that purpose. See also:
[C;3][LINK chip]        CHIP
[LINK fast]            FAST
[LINK public]            PUBLIC
[LINK attributes]        ATTRIBUTES
[LINK default]            DEFAULT
[J;1]
  Some symbols may be specified on the command line or into the \
WITH files. This creates an internal file. Also you may receive \
some errors and comments which occur with the file named: \
'Quick Defines'. See also:
[C;3][LINK define]        DEFINE
[J;1]
  If you always have an error because some branchement and JSR/JMP \
with PC generetes an overflow, you can use the instruction ALV to \
enable lk to create ALV tables (Thus are table of JMP instructions.)
  In the future versions, this will support more instructions, but \
this will probably generate some bugs at times.
  See also:
[C;3][LINK alv]            ALV
[J;1]
  lk supports relative definitions. This is complex to properly use \
those informations and be able to link objects most of the time. \
lk will always try to order hunks to fit the relative requirements. \
Except for tiny programs, a relative of 8 bits should be avoid or used \
a very small amount of times. If you use your own offset (See OFFSET \
instruction,) hunks may not be well ordered, generating overflow \
errors. If no error occur, the resulting code will always be working.
  The fact that lk keeps the BSS hunks at the end is important for \
users which want to use XDATA, CLEARXDATA or XRELATIVE instructions.
  lk will try to let BSS hunks at the end of the resulting hunk, this \
may not be possible when you use short and long relatives (16 and 32 \
bits.)
  lk keep a BSS hunk when all relative informations point to a BSS \
hunk, otherwise the hunk become a DATA hunk.
  lk will link a program with relative informations pointing to a \
hunk of CODE type. In this case only hunks of type code can be \
pointed.
  In the future versions, lk will be able to handle large d16(An) \
addressing mode and transform the instruction to accept 32 bits \
(Similarly the d8(An,Xn.S) will be transformed.)
  See also:
[C;3][LINK offset]        OFFSET
[LINK xhunk]            XCODE
[LINK xhunk]            XDATA
[LINK xhunk]            CLEARXCODE
[LINK xhunk]            CLEARXDATA
[LINK xhunk]            KEEPXDATA
[LINK xhunk]            XRELATIVEDATA
[J;1]
  A safer utilisation of lk, is to run it with a destination file \
in your RAM: disk.  Because this is the first version, it may \
remains a big bug (Even I tryed it in a lot of ways...)